Skip to content

fix(cliffs): the collision box is the RAW rectangle - #88 was wrong (#84) - #90

Merged
wormeyman merged 2 commits into
mainfrom
docs/cliff-accuracy-figure
Aug 2, 2026
Merged

fix(cliffs): the collision box is the RAW rectangle - #88 was wrong (#84)#90
wormeyman merged 2 commits into
mainfrom
docs/cliff-accuracy-figure

Conversation

@wormeyman

Copy link
Copy Markdown
Owner

Disassembly, prompted by flagging #88's fix as the thing I was least confident about. That flag was right: #88 scored best on every metric and was wrong about the mechanism.

What the engine actually does

It does not collide against rotbb's rectangle rotated 45°. It uses the raw stored rectangle and discards the orientation tag:

  1. EntityMapGenerationTask::tryToAddCliff (0x101625038) loads the box from proto + 0x5c0 + id*0x48 (20 bytes: four int32 edges at +4, orientation word at +0x14) and calls wouldCollide with Direction = 0 — literally mov x4, #0x0.
  2. wouldCollide (0x101625468) forwards box and direction to BoundingBox::BoundingBox(BoundingBox const&, Direction) (0x101c04380), then floors with (box + position) >> 8 over an inclusive tile rect.
  3. That constructor zeroes the destination, writes sentinel 0x80010000 into the destination's orientation word, and dispatches through a jump table whose entry 0 is 0 (read at 0x102d01400) — the identity arm, copying left_top/right_bottom verbatim. The source orientation is never read; the rotate arm is reachable only for a non-zero Direction.

Corroborated by the API mirror rather than disassembly alone: BoundingBox is documented as {MapPosition, MapPosition} or {..., RealOrientation} with orientation optional, and OrientedCliffPrototype::collision_bounding_box is a plain BoundingBox.

Three shapes, and the best-scoring one is wrong

box false rejections recall precision evidence
AABB (until #88) 13 0.9675 0.9743 an assumption
45° oriented rect (#88) 0 0.9758 0.9727 empirical fit only
raw stored rect (this PR) 6 0.9720 0.9713 disassembly + API docs

The middle row is the trap. It shrank the box past the engine's, and the excess shrinkage absorbed a different defect: 4 of the 6 cliffs the correct box still rejects are cells where our orientation disagrees with the game's, so we load the wrong box entirely. Those 4 belong to the standing orientation residual and should stay visible. A model that scores perfectly by hiding a second bug is worse than one that leaves it exposed.

Also

  • test/cliffOrientation.spec.ts asserted the opposite of this until now, on the stated reasoning that the AABB "is what the engine ends up scanning". Rewritten: the shipped box is the raw rectangle, it depends on intersect (the old file asserted independence), and its area is at most half the AABB's — though it is not contained in it, since a small intersect pushes hx past size/2. My first attempt asserted containment on every axis and failed for exactly that reason.
  • cliffBoxCoversTile and the separating-axis narrow phase are deleted. The broad phase alone is the whole rule, which is what the engine does.
  • Edges quantised to 1/256 — MapPosition is 8-bit fixed point, so x_dist's sqrt(2) cannot reach the engine at full precision.
  • Supersedes docs(cliffs): shipping orientation is 2.4%, not 2.0% (#84) #89, which was correcting a figure that has since moved again.

pnpm run verify green: 1311 passed / 3 skipped, 0 warnings.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WRKSNgkidxc6daeHGJHqpt

wormeyman and others added 2 commits August 1, 2026 22:01
The banner kept the pre-#88 figure. Since the collision box was corrected to
rotbb's rotated rectangle the rejection costs ZERO true positives, so the
shipping matched set is identical to the unfiltered one - 1531 either way, 37
wrong orientations, 2.42%. Measured on both paths.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WRKSNgkidxc6daeHGJHqpt
)

Disassembly, prompted by flagging #88's fix as the thing I was least confident
about. It was right to flag: #88 scored best on every metric and was wrong about
the mechanism.

The engine does NOT collide against rotbb's rectangle rotated 45 degrees. It uses
the RAW stored rectangle and discards the orientation tag entirely:

1. EntityMapGenerationTask::tryToAddCliff (0x101625038) loads the orientation's
   box from proto + 0x5c0 + id*0x48 (20 bytes: four int32 edges at +4, the
   orientation word at +0x14) and calls wouldCollide with Direction = 0 -
   literally `mov x4, #0x0`.
2. wouldCollide (0x101625468) forwards box and direction to
   BoundingBox::BoundingBox(BoundingBox const&, Direction) (0x101c04380), then
   floors with (box + position) >> 8 over an inclusive tile rect.
3. That constructor zeroes the destination, writes sentinel 0x80010000 into the
   destination's orientation word, and dispatches through a jump table whose
   entry 0 is 0 (read at 0x102d01400) - the identity arm, which copies
   left_top/right_bottom verbatim. The source orientation is never read; the
   rotate arm is reachable only for a non-zero Direction.

Corroborated by the API mirror: BoundingBox is documented as {MapPosition,
MapPosition} or {..., RealOrientation} with orientation OPTIONAL, and
OrientedCliffPrototype::collision_bounding_box is a plain BoundingBox.

| box                            | false rej | recall | precision | evidence   |
| ------------------------------ | --------- | ------ | --------- | ---------- |
| AABB (until #88)               | 13        | 0.9675 | 0.9743    | assumption |
| 45-degree oriented rect (#88)  | 0         | 0.9758 | 0.9727    | fit only   |
| raw stored rect (this)         | 6         | 0.9720 | 0.9713    | disasm     |

The middle row is the trap. It shrank the box past the engine's, and the excess
shrinkage absorbed a DIFFERENT defect: 4 of the 6 cliffs the correct box still
rejects are cells where our orientation disagrees with the game's, so we load the
wrong box entirely. Those 4 belong to the standing orientation residual and
should stay visible. A model that scores perfectly by hiding a second bug is
worse than one that leaves it exposed.

Edges are quantised to 1/256 - MapPosition is 8-bit fixed point, so x_dist's
sqrt(2) cannot reach the engine at full precision.

test/cliffOrientation.spec.ts asserted the OPPOSITE of this until now, on the
stated reasoning that the AABB "is what the engine ends up scanning". That block
is rewritten: the shipped box is the raw rectangle, it DEPENDS on intersect (the
old file asserted independence), and its area is at most half the AABB's - though
it is not contained in it, since a small intersect pushes hx past size/2. An
attempt to assert containment on every axis failed for exactly that reason.

cliffBoxCoversTile and the separating-axis narrow phase are deleted; the broad
phase alone is now the whole rule, which is what the engine does.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WRKSNgkidxc6daeHGJHqpt
@wormeyman
wormeyman merged commit 64b5b79 into main Aug 2, 2026
2 checks passed
wormeyman added a commit that referenced this pull request Aug 2, 2026
cliffOrientationOracle.spec.ts counts the residual and bounds it. This pins what
it looks like, because the shape is the lead and a change in shape is a change in
cause even when the count holds.

Measured after #83 (multisample grid), #86 (lava rejection) and #90 (raw
collision box):

- 37 of 1531 matched cells, and all 37 differ in EXACTLY ONE edge. Not one
  two-edge difference survives; before #83 the dominant mode was two edges
  (125 of 175), a whole corner on the wrong side of a band.
- Every one is an OVER-detection: the game reports a -to-none orientation and the
  port reports a crossing on that edge, never the reverse.
- Spread over all four edges (L11/R6/T7/B13) and all three regions (7/26/4), so
  it is not a directional off-by-one.

Two candidate causes are already eliminated, which is why the shape is worth
pinning rather than re-deriving next session:

- crossesCliff is EXACT. Disassembled at 0x10160c914 under 2.1.12 (the VA in
  cliffs-NOTES.md had moved); cliffPlacement.ts reproduces it line for line
  including the a<0||b<0 early-out, the boundary<e0 check, and the strict >0.5
  gate and strict crossing comparisons. No >=-vs-> slip exists to find.
- cliffiness_basic is EXONERATED. Substituting the game's own corner cliffiness
  leaves the count at exactly 37/1531.

So the residual is in the grid-4 cliff-elevation field - the one input in the
chain with no direct per-corner oracle. A single-edge, strictly one-directional
over-detection is what a small positive field offset looks like.

The direction assertion is the load-bearing one: if under-detections ever appear,
the cause has changed and that reading is dead.


Claude-Session: https://claude.ai/code/session_01WRKSNgkidxc6daeHGJHqpt

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
wormeyman added a commit that referenced this pull request Aug 2, 2026
#99 characterised the rule and stopped short of porting it, flagging one open
sub-question: whether driving it from our own resource model, rather than the
game's entities, is accurate enough. It is - and it costs exactly one cell.

Scored across all three oracle regions, driving `makeVulcanusOreRejection` off
the same field stack the ore overlay paints from:

| region | game | placed | fires | false rejections | surplus |
| --- | --- | --- | --- | --- | --- |
| [0,0] | 283 | 283 | 0 | 0 | 2 -> 2 |
| [1500,1500] | 885 | 900 | 20 | 0 | 42 -> 22 |
| [-1200,800] | 401 | 387 | 0 | 0 | 1 -> 1 |

Precision at [1500,1500] 0.953 -> 0.975 with the 858 true positives untouched.
**Recall is not touched anywhere**, which was the gate: this rule may only ever
cost precision.

Three variants were scored and the two that lose are kept in the spec rather
than dismissed in a comment, because #88/#90 already paid for that lesson here:

| variant | fires | correct of 31 | false rejections |
| --- | --- | --- | --- |
| base box, ores only (SHIPPED) | 20 | 20 | 0 |
| base box + geyser | 21 | 20 | 1 |
| per-orientation box | 23 | 21 | 2 |

The geyser arm is strictly HARMFUL - one more false rejection and not one
additional correct suppression - so it is implemented behind `includeGeyser`,
defaulting off. The per-orientation rotbb box catches one more true cell and
pays two kept cliffs for it; higher `correct` is exactly the trap.

Not claimed: the mechanism is still open (the disassembly says cliffs are placed
before any resource entity exists), and 11 of the 31 stay unexplained with the
box deliberately not widened to cover them. The spec pins that 11.

Lands as `CliffBands.cellRejects`, an opaque per-cell predicate beside
`tileCollides` - so the shared cliff core stays planet-agnostic, and the model
the specs score is the model the renderer ships. The predicate enumerates no
entities: the overlapping tiles follow in closed form (2 tiles for an ore
against the lava rejection's ~30), guarded by a wider brute-force scan.


Claude-Session: https://claude.ai/code/session_01GyN97UwFQmwZs1cg4QHS1c

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
wormeyman added a commit that referenced this pull request Aug 3, 2026
…0.9961 (#84) (#101)

* feat(cliffs): port the ORE -> CLIFF rejection (#84 item 1)

#99 characterised the rule and stopped short of porting it, flagging one open
sub-question: whether driving it from our own resource model, rather than the
game's entities, is accurate enough. It is - and it costs exactly one cell.

Scored across all three oracle regions, driving `makeVulcanusOreRejection` off
the same field stack the ore overlay paints from:

| region | game | placed | fires | false rejections | surplus |
| --- | --- | --- | --- | --- | --- |
| [0,0] | 283 | 283 | 0 | 0 | 2 -> 2 |
| [1500,1500] | 885 | 900 | 20 | 0 | 42 -> 22 |
| [-1200,800] | 401 | 387 | 0 | 0 | 1 -> 1 |

Precision at [1500,1500] 0.953 -> 0.975 with the 858 true positives untouched.
**Recall is not touched anywhere**, which was the gate: this rule may only ever
cost precision.

Three variants were scored and the two that lose are kept in the spec rather
than dismissed in a comment, because #88/#90 already paid for that lesson here:

| variant | fires | correct of 31 | false rejections |
| --- | --- | --- | --- |
| base box, ores only (SHIPPED) | 20 | 20 | 0 |
| base box + geyser | 21 | 20 | 1 |
| per-orientation box | 23 | 21 | 2 |

The geyser arm is strictly HARMFUL - one more false rejection and not one
additional correct suppression - so it is implemented behind `includeGeyser`,
defaulting off. The per-orientation rotbb box catches one more true cell and
pays two kept cliffs for it; higher `correct` is exactly the trap.

Not claimed: the mechanism is still open (the disassembly says cliffs are placed
before any resource entity exists), and 11 of the 31 stay unexplained with the
box deliberately not widened to cover them. The spec pins that 11.

Lands as `CliffBands.cellRejects`, an opaque per-cell predicate beside
`tileCollides` - so the shared cliff core stays planet-agnostic, and the model
the specs score is the model the renderer ships. The predicate enumerates no
entities: the overlapping tiles follow in closed form (2 tiles for an ore
against the lava rejection's ~30), guarded by a wider brute-force scan.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GyN97UwFQmwZs1cg4QHS1c

* test(cliffs): the budget FLIPPED - recall is now the bigger defect (#84)

Every cliff defect found since #18 has been a rule the port over-places without
(lava collision, the rotbb box shape, the ore suppression), so "find another
rejection" has been the shape of the work throughout. After #100 that is no
longer where the error is.

| region | surplus | missing | lava-killed | ore-killed | never generated |
| --- | --- | --- | --- | --- | --- |
| [0,0] | 2 | 2 | 2 | 0 | 0 |
| [1500,1500] | 22 | 27 | 3 | 0 | 24 |
| [-1200,800] | 1 | 15 | 1 | 0 | 14 |
| total | 25 | 44 | 6 | 0 | 38 |

**The port now misses more cells than it over-places, 44 to 25**, and 38 of the
44 are cells the crossings stage never produces at all - a different defect in a
different part of the port from everything solved so far.

`[0,0]` generates every cell the game does: its whole miss is the two the lava
rejection took, and `neverGenerated` is zero there. All 38 sit in the two
far-field regions, which agrees with #93 finding the port exact at [0,0] and
[-1200,800] at cliff_smoothing = 0 and still wrong at [1500,1500].

Also closes item 3 (the entity half of `Surface::wouldCollide`) UNPORTED, by
size rather than by difficulty - the same move that retired fixImpossibleCells
as a suspect. It is a rejection, and rejections can only remove cells: total
surplus is 25, which bounds what rocks and craters together could ever be worth
against a 44-cell recall gap they cannot touch.

The crater arm is settled exactly, since craters are already in the fixtures:
all 8 sit in [-1200,800] and not one touches a cell the port over-places, nor
any cliff the game kept. Worth zero. The rock arm needs no fixture - the ceiling
covers it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GyN97UwFQmwZs1cg4QHS1c

* test(cliffs): the recall gap was a QUERY-WINDOW ARTIFACT - recall is 0.9961 (#84)

Supersedes this branch's first commit, whose central claim was wrong.

`find_entities_filtered` selects entities whose BOUNDING BOX touches the query
area; `placedCells` emits cells whose CENTRE lies inside it. Different inclusion
rules, so the fixtures carry cliffs centred just outside the box and every one
has been scored as a miss.

| region | game rows | centred inside | centred OUTSIDE |
| --- | --- | --- | --- |
| [0,0] | 283 | 283 | 0 |
| [1500,1500] | 885 | 861 | 24 |
| [-1200,800] | 401 | 387 | 14 |

That is 38 cells - the entire apparent recall gap - and the port places 38 of 38
once the query box includes their centres. Every one is an agreement being
scored as a failure. The widening arm is the load-bearing one: "we never looked
there" alone is equally consistent with the port being wrong.

Corrected budget, both sides scored alike:

| region | game | port | matched | surplus | missing |
| --- | --- | --- | --- | --- | --- |
| [0,0] | 283 | 283 | 281 | 2 | 2 |
| [1500,1500] | 861 | 880 | 858 | 22 | 3 |
| [-1200,800] | 387 | 387 | 386 | 1 | 1 |
| total | 1531 | 1550 | 1525 | 25 | 6 |

**Recall 0.9961, precision 0.9839.** The 0.972 recall in the notes divided the
same 1525 matches by 1569 rather than 1531 - the match count was never wrong,
only the denominator.

All 6 missing cells are ones our own lava rejection removed; there is no cell
the port simply fails to generate. So precision is the only real defect left.

Consequently item 3 (the entity half of Surface::wouldCollide) is RE-OPENED.
The earlier commit closed it by size, arguing a rejection cannot help a 44-cell
recall gap - that argument died with the gap. With recall at 0.9961 the dominant
defect is the 25 surplus cells, which is exactly what a rejection removes.

The crater arm stays settled at zero (all 8 sit in [-1200,800], none touches a
surplus cell). The rock arm has no oracle capture at all, so capturing one is
the next step - now with a 25-cell target rather than a ceiling against it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GyN97UwFQmwZs1cg4QHS1c

* test(cliffs): the rock arm fails on the mechanism's own geometry (#84)

Completes the item 3 thread in this branch rather than opening a second PR for
it, since the previous commit had just re-opened it.

No rock capture is needed to kill it. `computeInternal` runs `generateCliffs`
before `generateEntities`, and `apply` runs `applyCliffs` (+124) before
`applyEntities` (+164), so within a chunk no rock exists when the cliff is
applied. A rock can only block a cliff from an ALREADY-GENERATED NEIGHBOUR,
which confines the whole mechanism to cells near a 32-tile chunk border.

| | n | near chunk border |
| --- | --- | --- |
| surplus | 25 | 11 = 44.0% |
| matched | 1525 | 673 = 44.1% |

The base rate to three significant figures. The surplus has no chunk-border
character at all, so the one geometry the mechanism is confined to is not where
the errors are.

The direct overlap test agrees and is deliberately the weaker arm: 3 of 25
surplus cells overlap a modelled rock against a 6.6% base rate (~1.7 expected),
which is nothing - and our rock placement is a salt-dependent roll whose
individual positions are unreliable exactly as the geyser's were in #100.

So item 3 explains approximately none of the 25, and is closed on the
mechanism's geometry rather than on the ceiling argument that died with the
recall gap. Remaining unexplained: 25 surplus, 6 missing (all lava-rejection
over-rejections), 33 wrong orientations.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GyN97UwFQmwZs1cg4QHS1c

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
wormeyman added a commit that referenced this pull request Aug 3, 2026
)

* feat(cliffs): port the ORE -> CLIFF rejection (#84 item 1)

#99 characterised the rule and stopped short of porting it, flagging one open
sub-question: whether driving it from our own resource model, rather than the
game's entities, is accurate enough. It is - and it costs exactly one cell.

Scored across all three oracle regions, driving `makeVulcanusOreRejection` off
the same field stack the ore overlay paints from:

| region | game | placed | fires | false rejections | surplus |
| --- | --- | --- | --- | --- | --- |
| [0,0] | 283 | 283 | 0 | 0 | 2 -> 2 |
| [1500,1500] | 885 | 900 | 20 | 0 | 42 -> 22 |
| [-1200,800] | 401 | 387 | 0 | 0 | 1 -> 1 |

Precision at [1500,1500] 0.953 -> 0.975 with the 858 true positives untouched.
**Recall is not touched anywhere**, which was the gate: this rule may only ever
cost precision.

Three variants were scored and the two that lose are kept in the spec rather
than dismissed in a comment, because #88/#90 already paid for that lesson here:

| variant | fires | correct of 31 | false rejections |
| --- | --- | --- | --- |
| base box, ores only (SHIPPED) | 20 | 20 | 0 |
| base box + geyser | 21 | 20 | 1 |
| per-orientation box | 23 | 21 | 2 |

The geyser arm is strictly HARMFUL - one more false rejection and not one
additional correct suppression - so it is implemented behind `includeGeyser`,
defaulting off. The per-orientation rotbb box catches one more true cell and
pays two kept cliffs for it; higher `correct` is exactly the trap.

Not claimed: the mechanism is still open (the disassembly says cliffs are placed
before any resource entity exists), and 11 of the 31 stay unexplained with the
box deliberately not widened to cover them. The spec pins that 11.

Lands as `CliffBands.cellRejects`, an opaque per-cell predicate beside
`tileCollides` - so the shared cliff core stays planet-agnostic, and the model
the specs score is the model the renderer ships. The predicate enumerates no
entities: the overlapping tiles follow in closed form (2 tiles for an ore
against the lava rejection's ~30), guarded by a wider brute-force scan.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GyN97UwFQmwZs1cg4QHS1c

* test(cliffs): the budget FLIPPED - recall is now the bigger defect (#84)

Every cliff defect found since #18 has been a rule the port over-places without
(lava collision, the rotbb box shape, the ore suppression), so "find another
rejection" has been the shape of the work throughout. After #100 that is no
longer where the error is.

| region | surplus | missing | lava-killed | ore-killed | never generated |
| --- | --- | --- | --- | --- | --- |
| [0,0] | 2 | 2 | 2 | 0 | 0 |
| [1500,1500] | 22 | 27 | 3 | 0 | 24 |
| [-1200,800] | 1 | 15 | 1 | 0 | 14 |
| total | 25 | 44 | 6 | 0 | 38 |

**The port now misses more cells than it over-places, 44 to 25**, and 38 of the
44 are cells the crossings stage never produces at all - a different defect in a
different part of the port from everything solved so far.

`[0,0]` generates every cell the game does: its whole miss is the two the lava
rejection took, and `neverGenerated` is zero there. All 38 sit in the two
far-field regions, which agrees with #93 finding the port exact at [0,0] and
[-1200,800] at cliff_smoothing = 0 and still wrong at [1500,1500].

Also closes item 3 (the entity half of `Surface::wouldCollide`) UNPORTED, by
size rather than by difficulty - the same move that retired fixImpossibleCells
as a suspect. It is a rejection, and rejections can only remove cells: total
surplus is 25, which bounds what rocks and craters together could ever be worth
against a 44-cell recall gap they cannot touch.

The crater arm is settled exactly, since craters are already in the fixtures:
all 8 sit in [-1200,800] and not one touches a cell the port over-places, nor
any cliff the game kept. Worth zero. The rock arm needs no fixture - the ceiling
covers it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GyN97UwFQmwZs1cg4QHS1c

* test(cliffs): the recall gap was a QUERY-WINDOW ARTIFACT - recall is 0.9961 (#84)

Supersedes this branch's first commit, whose central claim was wrong.

`find_entities_filtered` selects entities whose BOUNDING BOX touches the query
area; `placedCells` emits cells whose CENTRE lies inside it. Different inclusion
rules, so the fixtures carry cliffs centred just outside the box and every one
has been scored as a miss.

| region | game rows | centred inside | centred OUTSIDE |
| --- | --- | --- | --- |
| [0,0] | 283 | 283 | 0 |
| [1500,1500] | 885 | 861 | 24 |
| [-1200,800] | 401 | 387 | 14 |

That is 38 cells - the entire apparent recall gap - and the port places 38 of 38
once the query box includes their centres. Every one is an agreement being
scored as a failure. The widening arm is the load-bearing one: "we never looked
there" alone is equally consistent with the port being wrong.

Corrected budget, both sides scored alike:

| region | game | port | matched | surplus | missing |
| --- | --- | --- | --- | --- | --- |
| [0,0] | 283 | 283 | 281 | 2 | 2 |
| [1500,1500] | 861 | 880 | 858 | 22 | 3 |
| [-1200,800] | 387 | 387 | 386 | 1 | 1 |
| total | 1531 | 1550 | 1525 | 25 | 6 |

**Recall 0.9961, precision 0.9839.** The 0.972 recall in the notes divided the
same 1525 matches by 1569 rather than 1531 - the match count was never wrong,
only the denominator.

All 6 missing cells are ones our own lava rejection removed; there is no cell
the port simply fails to generate. So precision is the only real defect left.

Consequently item 3 (the entity half of Surface::wouldCollide) is RE-OPENED.
The earlier commit closed it by size, arguing a rejection cannot help a 44-cell
recall gap - that argument died with the gap. With recall at 0.9961 the dominant
defect is the 25 surplus cells, which is exactly what a rejection removes.

The crater arm stays settled at zero (all 8 sit in [-1200,800], none touches a
surplus cell). The rock arm has no oracle capture at all, so capturing one is
the next step - now with a 25-cell target rather than a ceiling against it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GyN97UwFQmwZs1cg4QHS1c

* test(cliffs): the rock arm fails on the mechanism's own geometry (#84)

Completes the item 3 thread in this branch rather than opening a second PR for
it, since the previous commit had just re-opened it.

No rock capture is needed to kill it. `computeInternal` runs `generateCliffs`
before `generateEntities`, and `apply` runs `applyCliffs` (+124) before
`applyEntities` (+164), so within a chunk no rock exists when the cliff is
applied. A rock can only block a cliff from an ALREADY-GENERATED NEIGHBOUR,
which confines the whole mechanism to cells near a 32-tile chunk border.

| | n | near chunk border |
| --- | --- | --- |
| surplus | 25 | 11 = 44.0% |
| matched | 1525 | 673 = 44.1% |

The base rate to three significant figures. The surplus has no chunk-border
character at all, so the one geometry the mechanism is confined to is not where
the errors are.

The direct overlap test agrees and is deliberately the weaker arm: 3 of 25
surplus cells overlap a modelled rock against a 6.6% base rate (~1.7 expected),
which is nothing - and our rock placement is a salt-dependent roll whose
individual positions are unreliable exactly as the geyser's were in #100.

So item 3 explains approximately none of the 25, and is closed on the
mechanism's geometry rather than on the ceiling argument that died with the
recall gap. Remaining unexplained: 25 surplus, 6 missing (all lava-rejection
over-rejections), 33 wrong orientations.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GyN97UwFQmwZs1cg4QHS1c

* test(cliffs): the orientation residual is not a boundary tie (#84)

Stacked on the error-budget branch.

The residual's known shape - exactly one edge per wrong cell, always an
OVER-detection - has an obvious cheap explanation that turns out to be wrong,
and ruling it out eliminates a whole class of cause.

`crossesCliff` decides on the sign of `elevation - boundary`. If an endpoint sat
within float noise of a band boundary, the ~1e-6 our fields agree to would flip
the crossing, and the residual would be an irreducible precision limit with
nothing to fix.

Measured: every crossing edge in a wrong cell sits at least 0.205 from its
boundary, median ~9.9 - four to seven orders of magnitude clear of float noise.
For the game to disagree its elevation must differ from ours by more than 0.2,
which is a real field or rule difference.

Non-vacuity: the overall minimum across all 2,920 crossing edges is 6.4e-3,
thirty times tighter, so "far from the boundary" is a property of the wrong
cells and not of the sample.

Also pins WHICH channel the corner fixture holds, as a number rather than as
prose: against our per-tile elevation the worst corner differs by 4.8e-2;
against the grid-4 cliff channel the generator actually reads, by 96.09. #83 was
the most expensive mistake this subsystem has made and prose is not a guard.

The gap that leaves is the point: the grid-4 cliff-elevation channel has NO
per-corner oracle, is the only placement input never checked against the game
corner by corner, and after the margin result is the only remaining candidate
that could move an endpoint the required 0.2. Capturing it is the next step -
and not via calculate_tile_properties, which is the 1-tile program that produced
the wrong-channel fixture in the first place.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GyN97UwFQmwZs1cg4QHS1c

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
wormeyman added a commit that referenced this pull request Aug 4, 2026
…e destroy stage (#84) (#124)

The section before this put 11 of the 25 missed destructions on the ore rule
and named widening it as the next move. The mechanism was worth one more look
first, because `vulcanusOreRejection.ts` has always said the rule is
characterised rather than ported. It should NOT be widened.

Entity collision is excluded, now VERIFIED by three routes rather than asserted
from the call ordering alone:

1. Order - `computeInternal` calls `generateCliffs` at +0x2c, before it even
   builds the NoiseCache the three `generateEntities` passes use; `apply` calls
   `applyCliffs`, `applyDecoratives`, `applyEntities` in that order.
2. Inputs - `generateCliffs`' entire call list is `crossingsForChunk`,
   `MaybeCliffOrientation::value`, `tryToAddCliff`. No resource input at all.
3. Masks, at the PROTOTYPE level rather than the type default - calcite,
   tungsten-ore and sulfuric-acid-geyser are all `type = "resource"` and none
   overrides `collision_mask`, so all take `{layers={resource=true}}` against
   the cliff's `{item, meltable, object, player, water_tile, is_lower_object,
   is_object, cliff}`. Disjoint.

Route 3 kills the variant nobody had written down: CROSS-CHUNK ordering. Chunk
N's entities really are on the surface before chunk N+1's cliffs are applied,
so "the resource was already there" is available as an escape - and it still
cannot matter, at any box size, because the masks never intersect.

The one entity-versus-cliff test that exists runs the other way: `applyEntities`
calls `Surface::mapGeneratorWouldCollide` per queued entity and SKIPS the entity
on a hit. It never destroys a cliff.

The stage is measured: applying #122's discriminator to the lever's 31 cells,
exactly one is decidable and it says DESTROYED (`1546,1550.5`, a geyser cell,
neighbour `1546,1546.5` at `north-to-none`). So the effect enters at
`applyCliffs`/`Surface::wouldCollide`, not at `crossingsForChunk`. n=1 - the
spec says so, and carries the contrast arm showing the other 30 cost nothing.

Consequence: widening the box would fit a shape to an unexplained effect rather
than model a code path - exactly what #88 shipped and #90 had to undo. Close the
recall gap by finding what the resource control actually changes.

Also records `Surface::mapGeneratorWouldCollide` (0x101624a44), which was in
neither notes file and is distinct from both other wouldCollide overloads.

Measurement only - nothing shipping changed.


Claude-Session: https://claude.ai/code/session_015jeznBmWiZywUc7cBw9xFU

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant